<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>

<head>
<title>Table 2: Immediate Subattributes of 'neighbor</title>
</head>

<body bgcolor="white">

&nbsp;<b>Table 2:  Immediate Subattributes of <code>neighbor</code></b><br>
<table align="center" border="1">

<tr>
<td align="center" valign="center">
<b>Attribute</b>
</td>
<td align="center" valign="center">
<b>Description</b>
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>as</code>
</td>
<td align="left" valign="center">
The NHI prefix address of this neighbor's AS.  In other words, the
global <code>id</code> of the <code>Net</code> which is the AS
boundary for this neighbor.  If it is identical to the NHI prefix of
the local BGP speaker's AS, then it is interpreted as an internal
neighbor.  Otherwise it is interpreted as an external neighbor.  This
is a required subattribute of <code>neighbor</code>.  (When
autoconfiguration is in use, a neighbor's AS will be identified
automatically.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>address</code>
</td>
<td align="left" valign="center">
For an external neighbor, this must be an NHI <i>interface</i> address
relative to the <i>neighbor's</i> AS.  For an internal neighbor it
must be an NHI <i>host</i> address relative to the <i>local</i> AS.
This is a required subattribute of <code>neighbor</code>.  (When
autoconfiguration is in use, a neighbor's address will be set to the
address of the physical interface on the end of the point-to-point
link which connects it to the local router.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>use_return_address</code>
</td>
<td align="left" valign="center">
The NHI interface address, relative to the local AS, which the
neighbor should use when sending messages to the local BGP speaker.
Often an internal peer will use the address of a virtual (loopback)
interface, while an external peer will typically use the address of a
physical interface on a point-to-point link.  This is a required
subattribute of <code>neighbor</code>.  (When autoconfiguration is in
use, the return address used by a neighbor is the address of the
physical interface on the local router which is on the end of the
point-to-point link which connects the local router to this neighbor.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>hold_time</code>
</td>
<td align="left" valign="center">
The value, in seconds, to be used as the proposed length of the Hold
Timer Interval during peering session establishment.  The actual Hold
Timer Interval, once determined, represents the maximum amount of time
which can elapse between the receipt of any two successive messages
(of type KeepAlive or Update) from a particular peer without loss of
connectivity to that peer.  This is a required subattribute of
<code>neighbor</code> if no global default value has been explicitly
configured.  (When autoconfiguration is in use and no global default
value has been configured, a neighbor will have an associated proposed
Hold Timer Interval value of <code>90</code>.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>keep_alive_time</code>
</td>
<td align="left" valign="center">
The value, in seconds, of the Keep Alive Timer Interval.  It
represents the maximum amount of time that should elapse between
successive messages (of type KeepAlive or Update) which are sent to a
peer.  The value may be adjusted during peering session establishment
when the Hold Timer Interval is negotiated, and also when jitter is
applied.  This is a required subattribute of <code>neighbor</code> if
no global default value has been explicitly configured.  (When
autoconfiguration is in use and no global default value has been
configured, a neighbor will have an associated Keep Alive Timer
Interval value of <code>30</code>.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>mrai</code>
</td>
<td align="left" valign="center">
The value, in seconds, of the Minimum Route Advertisement Interval
(MRAI).  It is the minimum amount of time which must elapse between
successive advertisements of routes regarding the same destination
which are sent to the same peer.  The value may be adjusted when
jitter is applied.  This is a required subattribute of
<code>neighbor</code> except when certain global default values have
been explicitly configured.  The MRAI for an internal neighbor need
not be specified if a global default value for MRAI for internal
connections has been configured.  The MRAI for an external neighbor
need not be specified if a global default value for MRAI for external
connections has been configured.  (When autoconfiguration is in use, a
neighbor will have an associated Minimum Route Advertisement Interval
value of <code>30</code>, unless global default values have been
configured as described above in the manual configuration case.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>ibgp</code>
</td>
<td align="left" valign="center">
This attribute is only meaningful if this is an internal neighbor and
if the local BGP speaker is itself a route reflector.  If that is the
case, then the presence of this attribute indicates that this neighbor
is in the same Internal BGP route reflection cluster as the local BGP
speaker.  The value of the attribute (either <code>reflector</code> or
<code>client</code>) indicates whether the neighbor is a reflector or
a client.  The omission of this attribute for an internal neighbor of
a route reflector indicates that it is not in a cluster with the local
BGP speaker, and thus is a non-client.  (When autoconfiguration is in
use, route reflection is not used.)
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>infilter</code>
</td>
<td align="left" valign="center">
Encapsulates the filtering policy for inbound route advertisements from this
neighbor.  A filter may permit or deny routes based on their attributes (which
include the routes' destination and their path attributes).  Furthermore, a
filter may arbitrarily modify the path attributes of permitted routes.  This is
a required subattribute of <code>neighbor</code>.  See <a
href="table3.html">Table&nbsp;3</a> for a description of its subattributes.
(When autoconfiguration is in use, a policy which permits all routes, without
modifying them, is used.)  <b>Note:</b>&nbsp;Filtering features are still in
the experimental stage.  Use with care.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>outfilter</code>
</td>
<td align="left" valign="center">
Encapsulates the filtering policy for outbound route advertisements to this
neighbor.  A filter may permit or deny routes based on their attributes (which
include the routes' destination and their path attributes).  Furthermore, a
filter may arbitrarily modify the path attributes of permitted routes.  This is
a required subattribute of <code>neighbor</code>.  See <a
href="table3.html">Table&nbsp;3</a> for a description of its subattributes.
(When autoconfiguration is in use, a policy which permits all routes, without
modifying them, is used.)  <b>Note:</b> filtering features are still in the
experimental stage.  Many aspects are as of yet unimplemented or untested.  Use
with care.
</td>
</tr>

</table>


<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>


</body>
</html>
